home *** CD-ROM | disk | FTP | other *** search
/ Internet Tools (InfoMagic) / Internet Tools.iso / dos_win / winsock / hacklist / 94-04.Z / 94-04 / 000000_alun@internet.wst.com_Thu Apr 3 02:49:00 1994.msg next >
Internet Message Format  |  1994-04-30  |  5KB
  1. Received: from internet.wst.com.wst.com ([198.64.82.8]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  2.           id AA12995; Thu, 31 Mar 1994 09:47:42 -0500
  3. Received: by internet.wst.com.wst.com (4.1/SMI-4.1)
  4.     id AA00735; Thu, 31 Mar 94 08:49:01 CST
  5. From: alun@internet.wst.com (Alun Jones)
  6. Message-Id: <9403311449.AA00735@internet.wst.com.wst.com>
  7. Subject: Re: What does send() returning 0 mean ? revisited
  8. To: paul@atlas.abccomp.oz.au
  9. Date: Thu, 31 Mar 94 8:49:00 CST
  10. Cc: winsock-hackers@sunsite.unc.edu
  11. In-Reply-To: <9403310450.AA25514@atlas>; from "paul@atlas.abccomp.oz.au" at Mar 31, 94 8:54 am
  12. X-Mailer: ELM [version 2.3 PL11]
  13.  
  14. > I'd like to conduct a straw-poll please, on the expected behaviour
  15. > of calling send() with a zero length - this seems to be one
  16. > case that different stacks handle quite differently, and there is currently
  17. > no guidance in the specification.
  18.  
  19. I would ask what the expected use of a send() call with zero length
  20. would be - is it just a device so that a programmer doesn't have to
  21. surround his send() calls with an if statement to check that the
  22. number of bytes is not zero?  If this is the only advantage of this
  23. approach, then I would advocate not allowing 0 as a number of bytes to
  24. send.
  25.  
  26. >         My thoughts are that this is a perfectly valid, though not
  27. > particularly useful, thing to do, and that this is the only time it
  28. > is valid for send() to return 0 - which indicates success, 'cause the
  29. > number of bytes able to be written == number of bytes requested.
  30. > Other stacks seem to call this an error, and Trumpet Winsock returns
  31. > SOCKET_ERROR with error code WSAEINVAL (Invalid Argument) [ although the
  32. > Error Codes section for send() indicates WSAEINVAL means "The socket
  33. > has not been bound with bind()"]
  34.  
  35. Being strictly pedantic, the documentation says that (on a
  36. non-blocking SOCK_STREAM socket, at least) the return value will be
  37. between 1 and the number of bytes requested, or the error condition.
  38. "Between" is one issue here - mathematically, I guess this could mean
  39. "between 1 and 0" if the number of bytes requested is 0, but a more
  40. English oriented reading implies that the number of bytes requested
  41. would be more than (or equal to) 1.
  42.  
  43. I believe that returning 0 if the number of bytes requested is greater
  44. than 0 is a BAD THING, since that means that no data could be sent, or
  45. stored for sending, which really means WSAEWOULDBLOCK (on non-blocking
  46. sockets).  Obviously, a blocking socket won't return anything until
  47. all of the bytes have been sent, or an error has occurred, so a
  48. blocking socket should either return an error condition, or the number
  49. you requested.  (Note that if you want to send a two/more part message
  50. out on a blocking port, and want to use the number returned from
  51. send() to determine where any error occurred, and which messages made
  52. it through, you should probably be looking at calling send() once for
  53. each message instead, or going to non-blocking sockets).
  54.  
  55. The only use I can see for _passing_ 0 bytes in to the send() function
  56. is to tell if all previous (non-blocking) sends have been sent through
  57. the transport layer, by setting the socket to blocking, and sending 0
  58. bytes.  A stack might then decide to block until all buffered output
  59. has been sent.  This is not described in the documentation, however,
  60. and would require either stack dependency (a BAD THING), or a new
  61. standard (a GOOD THING).  However, the approach of winsock seems to be
  62. that the application developer should not need to know when data has
  63. been sent through the transport, so even this would be a rather
  64. dubious functionality to ask for.
  65.  
  66. >     Comments from others, both stack developers and application
  67. > developers, please ....
  68.  
  69. As background, I am an application developer - I wrote cooksock and
  70. wftpd.  Wftpd seems to break quite a few stacks, since I tend to be
  71. somewhat pedantic about the things I expect from compliant stacks.
  72. I'm hoping that winsock stack developers have as open minded an
  73. approach to making their stacks more usable to winsock application
  74. developers, as they had to implementing the spec in the first place.
  75. I know that FTP Software are continually improving their software to
  76. make it more useful to other winsock developers, and I'd like to see
  77. similar approaches from the other winsock stack developers.
  78.  
  79. My other pet(ty) gripe is that there is (apparently) no freely
  80. available documentation about differences between various
  81. implementations of winsock.  When a user calls me and says "I can't
  82. get your program working on stack x", it would be nice to be able to
  83. search through a list of that vendor's differences from the winsock
  84. spec, and from other vendors - things like DNS compatibility, what
  85. kind of error values are returned, which functions aren't yet written,
  86. what assumptions had to be made that weren't covered in the spec -
  87. that sort of thing.  I would suggest that a "docs" area on sunsite
  88. might be a good place to store such information if it existed, but
  89. since sunsite isn't my site, I can't expect that such a thing would
  90. happen.  I'd offer this site, but we have a 14400 baud modem
  91. connecting us to the rest of the world, so I don't think that would be
  92. a great idea!
  93.  
  94. Alun.